FIG. 1 shows a conventional debug system 10 with direct memory access and trace support. The debug system 10 comprises a host computer 12, a debug tool 14, a low speed debug interface 16, a high speed trace capture and processing unit 18, a low-speed debug port 15, a high-speed trace port 17, a microcontroller device 20 and a system memory 36. The microcontroller device 20 includes an on-chip debug logic 22, a frame buffer 24, an on-chip debug control 26, a bus monitor 28, a memory interface 30, a CPU 32 and a bus matrix 34. Traditionally, electronic systems with advanced control or data processing requirements would contain separate CPU 32 and memory devices, soldered onto the same printed circuit board. During developing and debugging embedded software, it was thus possible to use logic analyzers to probe the system bus to identify and capture events useful for software debugging. With the advent of powerful microcontrollers with on-chip memories, the system bus resides within the device, and the bus events are no longer available for direct capture. The problem becomes particularly noticeable as microcontrollers become ever more complex, with a corresponding increase in software complexity. As many embedded systems involve real-time communication, control, or data processing, the debugging task becomes further complicated, as more debug features have to be non-intrusive, i.e., not disrupt the real-time software execution.
To avoid software development time increasing exponentially, on-chip debug (OCD) logic 22 is required to assist in observing and controlling the embedded processor through a set of debug features. A debug tool 14 interfaces between the development software on a host computer 12 and the OCD logic 22 through a debug port 15 (e.g. JTAG) and a trace port 17.
The most basic debug features involve intrusive control of CPU 32 operation. This includes breakpoints, to selectively halt the CPU 32 based on a specific condition, and methods to examine the CPU 32 registers and restart the CPU 32 to normal operation. These debug features are normally controlled by a set of debug registers, accessible through a debug interface, e.g., JTAG. As all real-time events are handled by the OCD logic 22, the debug tool 14 does not have to contain high-speed logic, and can be designed in a simple, low-cost fashion.
The basic debug features allow intrusive debug access to system memory 36 by halting the CPU 32, and issuing instructions to examine or alter the system memory 36. However, with the increasing complexity of embedded real-time systems, non-intrusive direct memory access to system memory 36 has become a requirement (e.g. Nexus 2.0 standard, IEEE ISTO5001™-2003, class 3). This enables the debug tool 14 to use the low-speed debug port 15 to observe and alter memory without requiring the CPU 32 to be halted.
More advanced are trace features which replace the traditional logic analyzers, and thus constitute an important part of on-chip debugging in complex microcontroller applications. This involves reconstructing the program or data flow of the embedded software to identify the point of incorrect program execution. This is accomplished by logging a sequence of characteristic debug events, collectively known as trace information, such as program branches, and system bus accesses, during the software execution. Data is supplied with each event to relate the event to the execution, allowing the exact execution sequence to be reconstructed.
Trace information is formatted into messages, consisting of frames, corresponding to one set of data on the trace port 17 of the device. The trace information is generated in bursts, resulting in a very high peak frame rate. The average frame rate is usually much lower, and it is therefore economical to keep the generated frames in a frame buffer 24, and transmit them through the trace port 17 at a frame rate closer to the average frame rate. The trace information can then be captured, stored, and analyzed by the debug tool 14.
The trace features are nevertheless very bandwidth intensive. The frame buffer 24 and dedicated trace port 17 add to the cost of the microcontroller 20. The high bandwidth also strongly increases the cost of the debug tool 14, which requires complex and expensive hardware to capture and process the vast amount of high-speed trace information.
The trace frames are normally stored in a large buffer within the debug tool 14, allowing for a relatively long real-time trace sequence to be captured. However, many software debug situations do not require the entire trace sequence, only the first messages (e.g. exit from an interrupt handler), or last messages (e.g. illegal entry to a trap). Thus, trace implementations with a limited trace buffer would still be highly valuable.
Accordingly, what is needed is a system and method for lowering the cost of implementing trace features both for the microcontroller and for the debug tools. The present invention addresses such a need.